An organization having an electronic information site such as a web site oftentimes may wish to track activities of users at the site. In particular, the organization may wish to create a record representing the presentation of each web page served to each requesting user. Reasons for creating such a record are many and varied, but typically involve: gathering data and other information that may be employed to perform statistical analyses of particular ones of the pages or of the site overall, such as for example regarding effectiveness, usability, perceived user experience, and the like; gathering data and other information that may be employed to establish use profiles of users overall or particular ones of users, such as average viewing time, typical actions performed, perceived preferences, and the like; and gathering data and other information that may be employed to establish technology profiles regarding technological aspects of the site, such as browsers employed to access the site, typical connection speeds, activities performed by servers connected with the site, and the like; among other things. Notably, one particular reason for creating such a record may be to establish proof that a user visited a particular web page or performed a particular action at particular web page, especially if the user may later deny such a visit or such an action, among other things.
One way to track such activity is to obtain the URL (Uniform Resource Locator) of each request from a user and store the obtained URL in an access log. As should be understood, such a URL typically includes a namespace, a hostname, perhaps an extension, and also perhaps a query string as generated at the web site. Thus, in the case of the URL:
http://www.example.com/search?sourceid=navclient&ie=UTF-8& q=searchstring
‘http://’ is the namespace, ‘www.example.com’ is the hostname, ‘/search’ is the extension, and ‘?sourceid=navclient&ie=UTF-8& q=searchstring’ is the query string.
Tracking by way of a URL is generally known as a form of web analytics. In such tracking, each time a page or an image is served by a web server, the web server automatically logs the URL, the IP address, browser type, and operating system of the requesting user, the date and time, the number of bytes, the return code, the referring page, cookies employed, and the like in a log file.
However, and as should be understood, the obtained URL from each request may not contain all the information that the organization wishes to track. For example, although the URL may indeed contain significant information regarding the activity, such URL does not necessarily contain all of the information that is desired by the organization for purposes of tracing activities of the user. Moreover, the query string portion such URL is an optional feature of a URL and is not always present, or if present may not necessarily be informative. Especially if the page associated with the screen is dynamically generated, and as should be understood, the URL can be the same across multiple served pages even where the pages are substantially different, and accordingly such URL can be of little real informative value in such a situation.
In order to augment web logs to capture the dynamic information, page tags have been employed in the prior art. Page tags are essentially references to invisible images with additional query parameters that are embedded in the results sent back to the requesting user. When a browser of such user attempts to resolve the images, the additional information can be added to the log. Page tags can be inserted either on the client side using javascript, or on the server side using servlets. Usually, page tags have a different domain name than the actual pages. This allows the server logs of the page tagging server to be completely dedicated for the purpose of web analytics. This also allows web analytics to be done as a hosted service.
However, in order to maintain insight into the unique source of the request, the page tagging server has to set and read a cookie. Since the domain is different than the encapsulating page, this is known as a third party cookie. Since this third party cookie can be set and read by the owner of the domain (the third party), it can be used by the third party to correlate all the pages across all domains that contain a reference to the third party. For this reason, many people became very averse to third party cookies and have refused to accept them. This causes web analytics results that use page tags to be unreliable.
Web server plug-ins have also been employed in the prior art to augment web logs and inject additional information and correlate first party page tags. However, there is some risk that the plug-in causes additional latency or risk of failure, and accordingly this solution is less than desirable.
Accordingly, a need exists for a method and mechanism by which a user at a site of an organization can be tracked. In particular, a need exists for such a method and mechanism where the query string of the URL of each served page from the organization includes useful tracking information.